「我已經把每個 agent 的範圍都限制好了、也要求只讀不寫、也比對過重複檔案該留哪一份——照理說應該不會再出狀況了吧？」
前面幾天講的規則（範圍限制、只讀不寫、重複檔案比對）都假設一件事：會同時碰這批檔案的，只有你自己派出去的那些 agent。 但真實情況可能不是這樣——今天要講一次「查到最後才發現,問題根本不在 agent 身上」的案例。
某次協作流程裡，一批應該各自獨立、互不重疊的檔案，陸續出現同一份任務被寫成兩種不同檔名的狀況。第一次遇到，直覺反應是「一定是某個 agent 逾越了範圍」，照著慣例的做法比對兩份檔案的時間戳，留下看起來符合原始指派路徑的那一份，刪掉重複的。
問題是，這種狀況重複出現了好幾次，而且有一次刪掉重複檔案後，隔沒多久同一個位置又冒出一份新的重複檔案——這時候「單一 agent 逾越範圍」這個解釋開始說不通了：已經被清理過的問題,不會無緣無故自己再發生一次，除非背後還有一個持續在動作的來源沒被找到。
進一步排查工作階段清單，才發現答案：這個目錄底下，同時存在另一個完全獨立、由使用者自己開啟的工作階段，正在進行跟這邊派出去的 agent 完全相同的任務。 兩邊互不知道對方存在，各自派出各自的 agent 去處理同一批工作，才會不斷冒出「表面上是 agent 逾越範圍造成的重複」，實際上根源是有兩個獨立的協調者，同時在指揮不同的 agent 群，卻沒有互相知會。
前面幾天講的規則，處理的都是「一個協調者、派出多個 agent」這種情境下的協調問題——範圍限制防止單一 agent 做過頭，只讀不寫讓查核跟修正分開，重複檔案比對是事後補救的機制。但這些規則有一個共同的前提：只有一個協調者在做決策。
當實際情況是「兩個獨立的協調者」同時存在，這個前提就不成立了。這時候即使每個 agent 個別的範圍都限制得很好，兩個協調者各自認為自己是唯一在動這批檔案的人，兩邊的決策完全沒有交集，衝突只會在檔案層級持續浮現，而且每次重複發生時，看起來都很像是「同一種老問題又犯了」，容易被誤判成「範圍限制沒做好」，而不是真正的根因：協調層級本身沒有對齊。
用一組對照來看這個差異：
❌ 只在 agent 層級找原因：
「這批檔案又重複了，一定是某個 agent 沒守住範圍限制，
我把它的 prompt 寫得更嚴格一點。」
→ 反覆修補同一個症狀，卻沒有意識到問題根本不在
單一 agent 的行為，而是有第二個協調者存在
✅ 往上一層檢查協調者本身：
「這批檔案重複發生的頻率不太對勁，已經清理過的問題
不該無緣無故再發生一次——先查一下有沒有其他工作階段
同時在動這個目錄，而不是只調整單一 agent 的指令。」
→ 找到真正的根因層級，而不是在症狀層級無限打補丁
「限制單一 agent 的行為範圍」解決的是協調者跟它派出去的 agent 之間的協作問題,解決不了「協調者本身有沒有跟其他協調者衝突」這個更高層次的問題——這正好是這個系列主題句的另一種樣貌：工具設計得再細緻，前提假設如果錯了（例如「只有一個協調者」），再細緻的規則也會在某個層級失守。
確認真的有其他並行工作階段之後，正確的處理方式不是繼續往下修補 agent 層級的規則，而是往上跟使用者確認協調範圍：是不是打算讓多個工作階段同時處理這個專案、如果是，各自負責哪個範圍、有沒有辦法先講好分工再各自派出 agent。這件事沒辦法靠任何一個工作階段自己單方面解決——因為問題的本質是「有兩個決策中心」，解法也必須發生在決策中心這個層級，而不是繼續在執行層級加規則。
第三部這七天，從「為什麼要委派給獨立 agent」開始，一路講到範圍逾越、重複檔案比對、只讀不寫、違規但改對的案例、範圍限制的具體寫法，最後收在這個案例。串起來看，這七天講的其實是同一件事在不同層級的樣貌：agent 需要邊界、委派需要規則、規則失守時需要追查根因——而根因不一定在你原本以為的那個層級。
回想你最近一次遇到「同樣的協作問題反覆發生」的情況：你是持續在同一個層級修補症狀，還是曾經往上一層確認過，問題的根因是不是根本不在你檢查的那個範圍裡？
明天進入第四部：從幾個真實查核過程裡抓到的案例，看事實查核這件事本身，實際運作起來會抓到哪些型態的錯誤。
iThome鐵人賽
看影片追技術